Import format

Importing via WebApi leverages a template that defines the layout of the import path. The import format must be created in ARM, menu Platform - WebApi - Import/export format. In addition, the user can associate each import method with one of the paths created as the default import format in ARM, menu Platform - WebApi. We will now look at two key features of creating a custom import format:

• ARM parameterization
• Import rules

ARM parameterization

Here is an example of an import format implemented in Arm that will be analyzed in depth in this article:

The import format parameterization form is composed of two sections:

• Header with the heading information that defines the template
• Object details that allows you to select the properties to be included in the layout

Header

.png)

<SalesOrder xlmns="OtherERP.SalesOrder">
    <ExternalId>1234</ExternalId>
    <ExternalSystem>OtherERP</ExternalSystem>
    <OperationType>Insert</OperationType>
<SalesOrder>

Object details

        <SalesOrder xlmns="OtherERP.SalesOrder">
            <ExternalId>1234</ExternalId>
            <ExternalSystem>OtherERP</ExternalSystem>
            <OperationType>Insert</OperationType>
            <Date>28/11/2023</Date>
            <Customer>
                <Code>15200</Code>
                <DetailCode>66227</DetailCode>
                <Description>CHIODI S.R.L.</Description>
            </Customer>
            <Company>Demo</Company>
            <Items>
                <ItemTag>
                    <Item>
                        <Code>002/690</Code>
                        <ItemClass>ELV</ItemClass>
                    </Item>
                    <VAT>22</VAT>
                    <Quantity>50</Quantity>
                    <Price>8</Price>
                </ItemTag>
                <ItemTag>
                    <Item>
                        <Code>85285</Code>
                        <ItemClass>500</ItemClass>
                    </Item>
                    <VAT>22</VAT>
                    <Quantity>12</Quantity>
                    <Price>11</Price>
                </ItemTag>
            </Items>
        </SalesOrder>

Import rules

The exposed import methods work with Insert or Update logic as default, using the lookup key applied in the method.
The user has the option of forcing the call execution as IMPORT/UPDATE/DELETE through the header tag OPERATION TYPE.
In addition, he can handle UPDATE/DELETE imports based on the Fluentis table Id simply by entering the field in the import path.
This will override the lookup key and apply a wired search by Id.
Finally, in case the user wants to keep and use Ids coming from external source system, it will be possible to exploit the External Id and External System header tags to create a dual key that will be used as a lookup key for INSERT/UPDATE/DELETE operations.
We can identify three parameterization scenarios:

SCENARIO 1: INSERT OR UPDATE

If we specify Nothing, Default business logic is used.

The import will work in INSERT or UPDATE based on the lookup key in the standard method code. The EXTERNAL Id, EXTERNAL SYSTEM and OPERATION TYPE header tags are not used and the Id property is not used.

• If the lookup key returns 0 records it will be executed INSERT
• If the lookup key returns 1 record it will be executed UPDATE
• If the lookup key application returns more than 1 record the procedure will return ERROR

If we specified Operation Type we could force the action to be performed:

• INSERT, if lookup key returns 0 record is performed INSERT otherwise ERROR
• UPDATE, if the lookup key returns 1 record is performed UPDATE otherwise ERROR
• DELETE, if the lookup key returns 1 record is performed DELETE otherwise ERROR

SCENARIO 2: IMPORT BY FLUENTIS ID

For imports that need to execute UPDATE or DELETE, it is possible to override the lookup key and perform a direct lookup using the autoincremental identifier (primary key) found in each Fluentis table adding the Id field to the path.

This option must be associated with the Operation Type header tag to define whether the action to be performed should be UPDATE or DELETE.

• For UPDATE in addition to the Id only properties to be modified should be reported. If the search by Id returns only one match UPDATE will be executed otherwise ERROR will be returned.
• For DELETE only the Id should be given. If the search by Id returns one match it will be performed DELETE otherwise ERROR will be returned.

SCENARIO 3: IMPORT BY EXTERNAL ID/SYSTEM

It is possible to manage INSERT/UPDATE/DELETE using the Id present in the data source system external to Fluentis, via External Id and External System header tags.
Valuing these tags during INSERT will save them in a separate system table to create a dual search key that will be used in further INSERT/DELETE steps.
Without a value for the Operation Type tag, the import as by default follows the INSERT or UPDATE flow, using the search key based on the EXTERNAL ID and EXTERNAL SYSTEM tags.

By valuing the Operation Type tag, it will be possible to force execution only in INSERT/UPDATE/DELETE with the same rules as in the previous scenarios, where the lookup key is based on the EXTERNAL ID and EXTERNAL SYSTEM tags.